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REMARKS 

Claims 1-20 and 35-38 are pending in the instant application. In the instant Final 
Office Action the Examiner has made the actions described below. 

Applicant has filed a Request for Continued Examination (RCE) in conjunction 
with this paper and respectfully requests reconsideration of the rejections in view of the 
following comments. 

Claim Rejections Under 35 U.S.C. $ 103(a) 

The Examiner has rejected claims 1-20 and 35-38 under 35 U.S.C. § 103(a) as 
being unpatentable over Eydelman (U.S. Patent Application Publication No. 
2002/0007420) in view of Wang et al. (U.S. Patent No. 7,039,037). Applicant 
respectfully traverses the outstanding rejections for the reasons discussed below. 

With respect to claims 1 and 35, one aspect of the presently claimed invention 
relates to configuring a protocol stack to operate in a push mode in which the protocol 
stack initiates the forwarding, to an application, of a first sequence of data packets 
received by the protocol stack. The Examiner asserts that Eydelman describes such a 
step, analogizing a "transport provider" to the claimed protocol stack and stating that 
Eydelman, Para. 0047, "(large receiving mode)" describes such a configuration step. 
Applicant respectfully asserts that the Examiner misconstrues Eydelman in view of the 
claimed elements. Specifically, the cited section of Eydelman describes how two 
transport providers (120 and 126) interact with each other to implement flow control, not 
how data is transferred from an application to a protocol stack. Moreover, the "large 
mode", is associated with the size of data and corresponding methodology of data transfer 
between two transport providers, not to whether transfer to an application is done in a 
push or pull fashion. 
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In particular, Eydelman, Para. 0034 describes that the large receiving mode relates 
to whether or not the receiving application 132 posted a set of receiving buffers 134 
directly when it accepted the request to receive data, not whether it is operating in a push 
or a pull mode with respect to its associated protocol stack (which the Examiner 
analogizes to transport provider 120). Moreover, Eydelman further describes two 
additional modes; the "small-receive-large-receive mode" and the "small receive mode," 
neither of which relate to whether a transfer from a protocol stack to an application is 
done in a push or a pull fashion. 

Applicant is further unable to find any description of "push" or "pull" mode 
operation between a protocol stack and an application in Eydelman, nor is Applicant able 
to find an analogous description. 

Accordingly, for at least this reason, Applicant respectfully submits that 
Eydelman fails to describe, at a minimum, the claimed element of configuring a protocol 
stack to operate in a push mode pursuant to which the protocol stack initiates the 
forwarding, to the application, of a first sequence of data packets received by the protocol 
stack. 

In addition, claims 1 and 35 further describe switching, responsive to a first input 
notification, the protocol stack from operation in a push mode to operation in a pull mode 
in which the application initiates the forwarding, to the application, of a second sequence 
of data packets received by the protocol stack. The Examiner asserts that Eydelman 
describes this step, citing to "(discovery mode, page 3 [0027], [0030], page 5 [0047])." 
Applicant respectfully submits that Eydelman misconstrues the cited section of Eydelman 
in view of the presently claimed invention. 

In particular, Eydelman Paragraph 0027 describes that the mechanism of transport 
between transport providers 120 and 126 may vary depending on whether a "message," 
which is a small data packet, is sent or whether RDMA is used (i.e., "[i]f the receiving 
buffer is set large enough, bulk data transfer through Remote Direct Memory Access 
(RDMA) as known by those of skill in the art is used"). Paragraph 0027 does not, 
however, describe anything about whether transfer of data between a protocol stack and 
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an application is done in a push or pull fashion, or in particular whether the execution is 
switched between the two. 

Likewise, Eydelman Para. 0030 is similarly deficient. Specifically, Para. 0030 
describes the "discovery mode" as a mechanism for determining the ability of the 
application 132 to receive data. If the behavior is consistent for a select number of data 
transfers, the transport provider will adapt the way it provides data to the application 132 
to provide the best performance. This process is further illustrated in FIGS. 6 and 7, 
with Eydelman stating that "FIGS. 6 and 7 are representative of the steps that each 
transport provider's 120, 260 protocol performs in discovery mode" [Eydelman, Para. 
0030]. FIG. 6 of Eydelman illustrates a system of "credits," for sharing between 
transport providers [Para. 0062], while FIG. 7 illustrates steps to "minimize the number 
of kernel transitions" [Para. 0079]. However, neither of these figures and their associated 
text, which describe the "discovery mode," relate to an application transitioning from 
push to pull mode - they purportedly show transport provider to transport provider 
interaction, not application to protocol stack interaction. 

Consequently, for at least the above-described reasons, Eydelman fails to describe 
the above-described elements of claims 1 and 35 as asserted by the Examiner, and 
therefore the rejection is improper. 

In addition to the above-described deficiencies, the Examiner acknowledges that 

Eydelman does not teach generating, at the application, a first input notification 

determinative of an operative mode of the protocol stack. The Examiner also 

acknowledges that Eydelman does not teach switching, responsive to the first input 

notification, the protocol stack from operation in the push mode to operation in the pull 

mode. To attempt to cure this deficiency, the Examiner asserts that Wang describes these 

aspects of the method of claim 1 : 

"Wang teaches generating, at the application (WAP controller), a first input 
notification (request) determinative of an operative mode of the protocol stack 
(requesting a service)(Col 9 lines 15-23); and switching, responsive to the first 
input notification, the protocol stack from operation in the push mode to operation 
in a pull mode (Col 9 lines 15-32, the pull mode is initiated by a WAP device 
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requesting a service or information from a server, therefore if the system is 
currently in a push mode and receives a request from WAP device, the system 
will switch from the push more [sic] to the pull mode in response to the request)." 
[Final Office Action, Page 3] 

Applicant first addresses the Examiner's contention that "Wang teaches 
generating, at the application (WAP controller), a first input notification (request) 
determinative of an operative mode of the protocol stack (requesting a service)(Col 9 
lines 15-23)". Applicant respectfully disagrees that the cited portion of Wang describes 
generation by the WAP controller (allegedly corresponding to the claimed application) of 
any sort of "notification determinative of an operative mode" of a WAP device by virtue 
of "requesting a service". This is because the WAP device, not the WAP controller, in 
Wang's system operates to request a service ("The pull traffic is initiated by a WAP 
device requesting a service")(Wang, col. 9, lines 20-21). Accordingly, Wang fails to 
describe generating an input event at an application by virtue of any "request" for a 
service issued by Wang's WAP device, and instead describes a WAP device which is 
itself configured to request a service. 

In the Advisory Action in the instant application dated May 27, 2009 the 
Examiner states the he made a typo in citing the "WAP Controller" and that he really 
meant that "the application is really the WAP device (Col. 9, lines 15-32, the pull mode is 
initiated by a WAP device (application) requesting (input notification) a service or 
information from a server") [Advisory Action, Page 2, 1 st paragraph]. 

Based on these comments it appears that the Examiner is asserting that Wang 
describes that the WAP device performs the claimed step of generating, at the 
application, a first input notification determinative of an operative mode of the protocol 
stack. However, even if, for purposes of argument, this is correct, the cited section of 
Wang fails to describe anything about generating a first input notification determinative 
of an operative mode of the protocol stack - Wang describes, at most, that pull traffic is 
"initated by a WAP device requesting a service (e.g., prepaid operations, security 
changes, etc.) or information from a server" [Col. 9, lines 21-22]. However, Wang 
further describes that push traffic bypasses the WAP controller (which the Examiner 
asserts is analogous to the claimed protocol stack); i.e., "[p]ush notifications identify 
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WAP devices by their MSISDN and generally bypass the WAP controller (234) as shown 
at the bottom of FIG. 3" [Col. 9, lines 24-27]. As such, Wang cannot describe the 
claimed element of generating, at the application, a first input notification determinative 
of an operating mode of the protocol stack, since the "WAP controller" of Wang is 
described as not having different operating modes (i.e., as Wang describes, the WAP 
controller only operates in a single ("pull") mode. 

In addition, since Wang describes that the WAP controller is not used in 
conjunction with a push mode of operation, combination of Wang with Eryurek would be 
improper since Wang describes that no switching of operating modes is done in the WAP 
controller. 

Applicant additionally notes that claims 1 and 35 recite that a first sequence of 
data packets received by the protocol stack are forwarded to the application in the push 
mode, and that a second sequence of data packets received by the protocol stack are 
forwarded to the application in the pull mode. That is, both the claimed "push mode" and 
"pull mode" contemplate that data packets received by a protocol stack are forwarded to 
an application. It follows that although the term "push traffic" and "pull traffic" are used 
within Wang, Wang does not describe a "push mode" as presently claimed since this 
mode requires a forwarding of previously received data packets from a protocol core to 
an application. In this regard it is clear that Wang does not describe forwarding 
sequences of data packets received by the WAP controller to the WAP device - Wang 
explicitly states that the WAP controller is bypassed in push mode [Col. 9, lines 36-27 
and FIG. 3]. And any alleged teaching by Eydelman of the claimed "push mode" and/or 
"pull mode" is irrelevant in this regard, since the combination of Eydelman and Wang 
could only yield the claimed invention to the extent both Eydelman and Wang describe 
both t he claimed push and pull modes, which they do not. 

Finally, even assuming for the sake of argument that Wang describes the 
equivalent of the claimed protocol stack and application, Eydelman clearly and 
unambiguously teaches away from the approach alleged by the Examiner to be described 
by Wang; namely, the determination by an application of a transfer mode (i.e., push or 
pull) through generation of an input notification event. Rather, Eydelman describes a 
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system in which an opposite approach is used, i.e., transport providers allegedly 
corresponding to the claimed "protocol stack" decide which type of transfer mode to use. 
This is clearly described in, for example, Eydelman Paragraphs 0029 and 0030. 
Moreover, as discussed previously, in Wang there is no need for such switching in the 
WAP controller since it is assumed that it does not handle push mode operations. 
Accordingly, the Examiner's combination of Eydelman and Wang is clearly improper 
and would not yield an operative system. 



For at least the above-described reasons, Applicant respectfully submits that the 
rejections of claim 1 and 35 under 35 U.S.C. § 103 are improper. Therefore, Applicant 
requests that the rejections be withdrawn and claims 1 and 35 be allowed. 



With respect to claims 2 and 36, the Examiner asserts that Eydelman describes 
transitioning from push mode to pull mode in response to a first input notification, 
wherein the push mode and the pull mode are mutually exclusive modes of operation, 
citing only to paragraph 0027. Applicant respectfully submits that the Examiner 
misconstrues Eydelman in view of the claimed element. Specifically, paragraph 0027 
reads as follows: 

0027] Each transport provider 120, 126 provides a flow control protocol to 
synchronize data transfer for small data transfers and large data transfers. 
One reason for this is that the applications 132, 136 may exhibit different 
behavior when receiving data. The application may not post a set of 
receiving buffers until it is informed that data is available to be received or 
the application may post a set of receiving buffers when it requests to 
receive data. The application's set of receiving buffers may also be large or 
small. The set of receiving buffers could be a single buffer or an array of 
buffers. If the receiving buffer set is large enough, bulk data transfer 
through Remote Direct Memory Access (RDMA) as known by those 
skilled in the art is used. The threshold size for using bulk data transfer is 
based upon justifying the cost of initiating RDMA. Each RDMA operation 
has a cost which is a function of the control messages exchanged by the 
transport providers 120, 126, and the SAN NIC hardware operations 
needed to support RDMA operation. The transport provider 120, 126 
queries the SAN provider for the threshold size. Typically, the threshold 
size for a SAN provider is in the range of 2 KB to 4 KB. It should be noted 
that RDMA could be used for smaller data sizes than the threshold size. 
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Contrary to the Examiner's assertions, this paragraph says absolutely nothing 
about switching from push mode to pull mode or that the two modes are exclusive modes 
of operation. As noted previously, paragraph 0027 merely describes that bulk data 
transfer through RDMA may be used if the receiving buffer size is large enough. 
Moreover, Applicant is unable to find any description elsewhere in Eydelman of the 
claimed elements. 

Applicant respectfully notes that, in applying a rejection under 35 U.S.C. § 103, 
the Examiner cannot rely on generally pointing to the references to support a claim that 
each limitation is taught. To establish prima facie obviousness of a claimed invention, all 
the claim limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 
981, 180 USPQ 580 (CCPA 1974), see also MPEP § 2143.03. Consequently, 
establishing that all the claim limitations are taught requires that, for references like 
Eydelman, "the particular part relied on must be designated as nearly as practicable" by 
the Examiner. See, e.g., Rule 1.104 (c)(2). This Office Action, however, does not show 
with any specificity what construct or language from Eydelman corresponds to all of the 
elements of claims 2 and 36, and the cited section says absolutely nothing about push or 
pull modes or mutual exclusivity of the modes. Without more, the Office Action has 
failed to meet the standard for a prima facie case of obviousness and is therefore 
improper. 

Accordingly, for at least the above described reasons, the rejections of claims 2 
and 36 are improper, and Applicant respectfully requests that they be withdrawn and the 
claims be allowed. 

With respect to claim 3, the Examiner asserts that Eydelman describes 
transitioning from pull mode to push mode in response to a second input notification, 
citing only to paragraph 0027. Applicant respectfully submits that the Examiner 
misconstrues Eydelman in view of the claimed element. More specifically, paragraph 
0027 says absolutely nothing about switching from pull mode to push mode. As noted 
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previously, paragraph 0027 merely describes that bulk data transfer through RDMA may 
be used if the receiving buffer size is large enough. Moreover, Applicant is unable to 
find any description elsewhere in Eydelman of the claimed elements. Therefore, for at 
least these reasons, the rejection of claim 3 is improper, and Applicant respectfully 
requests that it be withdrawn and the claims be allowed. 

With respect to claims 4, 5, 37 and 38, the Examiner asserts that Eydelman 
describes that the input notifications include a receive sequence number corresponding to 
a sequence number of a data packet which, upon receipt at the protocol stack, induces 
transitioning the system from operation in the pull mode or push mode, citing only to 
paragraph 0027. Applicant respectfully submits that the Examiner misconstrues 
Eydelman in view of the claimed element. More specifically, paragraph 0027 says 
absolutely nothing about providing an input notification, switching responsive to the 
input notification, or that the notification includes a receive sequence number. As noted 
previously, paragraph 0027 merely describes that bulk data transfer through RDMA may 
be used if the receiving buffer size is large enough. Moreover, Applicant is unable to 
find any description elsewhere in Eydelman of the claimed elements. 

Applicant further notes that, in applying a rejection under 35 U.S.C. § 103, the 
Examiner cannot rely on generally pointing to the references to support a claim that each 
limitation is taught. To establish prima facie obviousness of a claimed invention, all the 
claim limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 981, 
180 USPQ 580 (CCPA 1974), see also MPEP § 2143.03. Consequently, establishing that 
all the claim limitations are taught requires that, for references like Eydelman, "the 
particular part relied on must be designated as nearly as practicable" by the Examiner. 
See, e.g., Rule 1.104 (c)(2). This Office Action, however, does not show with any 
specificity what construct or language from Eydelman corresponds to all of the elements 
of claims 4 & 5 - it merely refers to paragraph 0027, without anything further. As noted 
above, paragraph 0027 describes none of the claimed elements and the Examiner has not 
explained how any of the other description of paragraph 0027, or elsewhere in Eydelman, 
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describes the specifically claimed elements. Without more, the Office Action has failed 
to meet the standard for a prima facie case of obviousness and is therefore improper. 

Therefore, for at least the above-described reasons, the rejections of claims 4, 5, 
37 and 38 are improper, and Applicant respectfully requests that they be withdrawn and 
the claims be allowed. 

With respect to claims 7-9 s the Examiner asserts that Eydelman describes the 
various elements of these claims related to processing a received message by sending the 
received message from a protocol stack to an application, citing merely to Para. 0056. 
Applicant notes that these claimed elements relate to a protocol processing core 
transferring data to an application. However, the cited section of Eydelman relates to an 
application program sending data (not receiving it), in the form of a "small send." 
Specifically, Para. 0056 is a single sentence that reads as follows: 

[0056] 1. When a small send happens, copy the data to a send buffer from 
the set of buffers 140 and leave enough space at the beginning of the send 
buffer to put in the RDMA receive advertisement in the header and start a 
timer. 

Applicant fails to see how this describes the claimed element. Specifically, this 
section say nothing about processing to receive data - it describes copying data to be sen! 
to a "send buffer" and leaving space to include an "RMA receive advertisement." As 
such, the cited section of Eydelman is irrelevant to claims 7-9. Moreover, Applicant is 
unable to find any description elsewhere in Eydelman of the claimed elements. 

Therefore, for at least the above-described reasons, the rejections of claims 7-9 
are improper, and Applicant respectfully requests that they be withdrawn and the claims 
be allowed. 

With respect to claims 10 and 11, the Examiner asserts that Eydelman describes 
the various elements of these claims related to utilizing a credit-based flow control during 
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operation in the push mode based on the application providing buffer credits to the 
protocol stack, citing to Paragraphs 0064 and 0068-70. Applicant notes that these 
paragraphs of Eydelman describe providing credits between two transport providers 
(which the Examiner analogizes to the claimed protocol stack), not between an 
application and protocol stack as is presently claimed. Specifically, Eydelman Para. 0064 
describes that "the transport provider 120 provides a credit to the transport provider 126." 
This is not, however, what is presently claimed in claims 1 0 and 1 1 , which describe that 
the application is configured to provide buffer credits to the protocol stack (not transport 
provider to transport provider as described by Eydelman) and therefore the cited section 
of Eydelman is not relevant to these claims. 

Therefore, for at least the above-described reasons, the rejections of claims 10 and 
11 are improper, and Applicant respectfully requests that they be withdrawn and the 
claims be allowed. 

With respect to claims 12-19, the Examiner has merely cited paragraph 0027 and 
0047, without any further description of how these sections describe all of the claimed 
elements of these various claims. As such, this cursory rejection is an omnibus rejection 
of claims 12-19 based merely on referencing two paragraphs of Eydelman, without 
anything further. More particularly, the Examiner has stated nothing in the substantive 
Detailed Action regarding the specific basis for the rejection of each of claims 12-19 or 
where in the cited art each element of each claim is described. Claims 12-19 each 
include different scopes of protection, and Applicant respectfully notes that, per MPEP § 
707.07(d), all grounds for rejection must be "fully and clearly stated." As such, omnibus 
rejections are improper under MPEP § 707.07(d), and therefore, to the extent that the 
Examiner believes that these claims are not patentable, Applicant respectfully requests 
the Examiner to provide a detailed discussion as to the manner in which the cited art 
reads on each element of each of these claims in a non-final action. 
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For at least the above-described reasons, Applicant respectfully submits that the 
rejections of claims 1-20 and 35-38 under 35 U.S.C. § 103 are improper. Accordingly, 
Applicant requests that the rejections be withdrawn and the claims be allowed. 

New Claims 

Applicant has added new dependent claims 39-44 as fully supported by the 
Specification and Drawings of the present application as filed, including, in particular, 
Specification pages 45-53. For at least the above-described reasons, Applicant believes 
these claims are also allowable, and therefore requests that they also be allowed. 

Concluding Comments 

As noted previously, Applicant has filed an RCE in conjunction with this paper. 

It is believed that all of the pending claims have been addressed in this paper. 
However, failure to address a specific rejection, issue, or comment does not signify 
agreement with or concession of that rejection, issue, or comment. In addition, because 
the arguments made are not intended to be exhaustive, there may be reasons for 
patentability of any or all pending claims (or other claims) that have not been expressed. 
Finally, nothing in this paper should be construed as an intent to concede any issue with 
regard to any claim except as specifically stated in this paper. 

Applicant respectfully requests consideration of the remarks herein prior to 
further examination of the above-identified application. The undersigned would of 
course be available to discuss the present application with the Examiner if, in the opinion 
of the Examiner, such a discussion could lead to resolution of any outstanding issues. 
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The Director is hereby authorized to charge any appropriate fees under 37 
C.F.R.§§ 1.16, 1.17, and 1.21 that may be required by this paper, and to credit any 
overpayment, to Deposit Account No. 50-1283. 
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